Method and device to configure real-time networks

ABSTRACT

A method to configure nodes in a real-time network, which nodes are connected with links to each other directly or indirectly via other nodes and communicate with each other using said links by exchanging frames, wherein: (i) at least one node (a) associates at least one queue with at least one link, (b) is connected to said at least one queue, and (c) places frames in said at least one queue for transmission on the associated link, (ii) said at least one queue is associated with a gate which can be in an open or closed state, (iii) said at least one node selects frames that are placed in said at least one queue on the at least one link associated with said queue for transmission if the gate associated therewith is in the open state and does not select frames for transmission when said gate is in the closed state, (iv) said gate changes the state with the progress of time from open to closed and vice versa to form windows as indicated by configuration data, (v) said configuration data is produced by a tool capable of solving constraints in array theory, (vi) said tool accepts input formulated as constraints in array theory, (vii) said input is provided to said tool by human user input and/or by communication requests from one or more nodes in the real-time network, and (viii) said configuration data is communicated to one or more nodes in the real-time network, nodes which apply part or all of said configuration data as local configuration.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to European Patent Application No. 17194686.6, filed Oct. 4, 2017, which is incorporated herein by reference.

FIELD OF TECHNOLOGY

The invention relates to a method for configuring nodes in a real-time network, which nodes of the real-time network are connected with links to each other directly or indirectly via other nodes and communicate with each other using said links by exchanging frames, wherein at least one node associates at least one queue with at least one link, wherein said at least one node is connected to said at least one queue, and wherein said at least one node places frames in said at least one queue for transmission on the associated link, and wherein said at least one queue is associated with a gate which can be in an open state or in a closed state, and wherein said at least one node selects frames that are placed in said at least one queue on the at least one link associated with said queue for transmission if the state of the gate associated with said queue is in the open state and does not select frames for transmission from said queue on said link when said gate is in the closed state, and wherein said gate changes the state with the progress of time from open to closed and from closed to open to form windows as indicated by configuration data.

Furthermore the invention relates to a device to configure nodes in a real-time network as mentioned above.

Finally, the invention relates to a real-time network comprising at least one device for configuring node according to the invention.

The invention relates to generating configuration data for networks with real-time guarantees. For example such a real-time network may implement IEEE 802.1Qbv [1] which defines a time-aware shaping mechanism for the transmission of scheduled frames. A time-aware shaper is a gating mechanism executed at the egress side of a queue. This gating mechanism dynamically enables or disables the selection of frames from the respective queue based on a predefined configuration data. In the example of IEEE 802.1Qbv this configuration data GCL is referred to as Gate Control List.

In particular, IEEE 802.1Qbv defines a gate for each queue of an egress port, which at a given time can be in one of two defined states: open or closed. When the gate is in the open state, frames may be selected from the respective queue for transmission to the physical link in first-in first-out order. If the gate is in the closed state, frames from the respective queue are not selected. The points in time of state changes are calculated offline and the state changes are then executed during operation with respect to a synchronized time in the network.

SUMMARY OF THE INVENTION

It is an objective of the invention to ease the configuration of real-time networks as well as to improve the performance of generation of configuration data.

This objective is achieved with a method described above, which is characterized in that said configuration data is produced by a tool, wherein said tool is capable of solving constraints in array theory, and wherein said tool accepts input, which input is formulated as constraints in array theory, and wherein said input is provided to said tool by means of human user input and/or by means of communication requests from one, two, or more nodes in the real-time network, and wherein said configuration data is communicated to one, two, or more nodes in the real-time network, node or nodes which applies/apply at least parts of said configuration data or said configuration data as local configuration.

Furthermore, this objective is achieved with a device mentioned above, characterized in that the device is capable of producing configuration data by executing a tool, where said tool is capable of solving constraints in array theory, and wherein said tool is configured to accept input, which input is formulated as constraints in array theory, wherein said input is provided to said tool by means of human user input and/or by means of communication requests from one, two, or more nodes in the real-time network, and wherein the device is configured to communicate said configuration data to the one, two, or more nodes in the real-time network, which applies/apply at least parts of said configuration data as local configuration.

Finally, this objective is achieved with a real-time network described in the introduction, wherein for configuring nodes of the real-time network the real-time network comprises at least one device as mentioned above.

The configuration method is disclosed via the formulation of constraints encoding the dependencies between variables denoting among others the open and close instants of time for scheduled windows as well as the assignment of transmitted frames to a particular window. The encoding of these constraints may be formalized in different ways, enabling the use of tools like specialized solvers to search for a satisfiable solution. We particularly address the appropriateness of first-order theory of arrays (also called theory of arrays or array theory in this application) [2] as a suitable means of encoding the constraints derived from the scheduling problem that can be then solved by general purpose tools, like SMT solvers.

The first-order theory of arrays (ℑ_(A)) is build around two interpreted function symbols: select, used to return an element of an array from a certain index, and store, used to write an element into an array at a certain index. In addition to the usual operators from linear integer arithmetic, we use the syntax presented in [2] to introduce array theory and express the scheduler constraints. Usually, the signature of ℑ_(A) is defined as Σ_(A): {·[·],·

·←·

,=}. In [2], the sorts array, elem, and index are used for arrays, elements, and indices, respectively. Furthermore, the syntax a[i] is used for the select function of the element at index i from array a and a

i←e

is used for the store operation of element e in array a at index i. The main two axioms of array theory are [2]:

∀a:array, ∀i,j:index, ∀x:elem

i=j→a

i←x

[j]=x

i≠j→a

i←x

[j]=a[j]

Together with axioms of linear integer arithmetic these form the theory of integer-indexed arrays (

) which we use to express our scheduling constraints.

Advantageous embodiments of the method, the device, and the real-time network described above are detailed hereinafter:

-   -   Some of the constraints in array theory may be well-formed         windows constraints and/or queue assignment constraints and/or         stream instance constraints and/or ordered windows constraints         and/or frame-to-window assignment constraints and/or window size         constraints and/or stream constraints and/or stream isolation         constraints.     -   An SMT-solver may be used as said tool that is capable of         solving expressions in array theory.     -   OPC/UA and/or DDS and/or NETCONF/YANG and/or SNMP and/or FTP is         or may be used to communicate the communication requirements to         said tool and/or to communicate configuration data to the nodes.     -   Each node of the real-time network may be one selected from a         group consisting of an Ethernet switch, a router and an end         station.     -   The state change from open to closed and closed to open may be         executed according the IEEE 802.1Qbv standard.     -   A synchronized time may be established in the nodes, preferably         by means of the IEEE 1588 standards and/or the IEEE 802.1AS         standards and/or the SAE AS6802 standard or any revision of said         standards.

BRIEF DESCRIPTION OF FIGURES

In the following, in order to further demonstrate the present invention, illustrative and non-restrictive embodiments are discussed, as shown in the drawings. In the drawings

FIG. 1 depicts an example of a real-time network according to the state-of-the-art,

FIG. 2 depicts an example of a stream and frames according to the state-of-the-art,

FIG. 3 depicts an example realization of a node according to the state-of-the-art,

FIG. 4 depicts an example of a communication scenario according to the state-of-the-art,

FIG. 5 depicts a flowchart of an example of a method according to the invention,

FIG. 6 depicts constraints in array theory being used in a method according to the invention, and.

FIG. 7 depicts a device according to the invention for generating configurations for nodes in a real-time network.

EXEMPLARY EMBODIMENTS

We discuss some of the many implementations of the invention next. If not stated otherwise, all details described in connection with a specific example are not only valid in connection with this example, but apply to the general scope of protection of the invention.

FIG. 1 depicts an example of a real-time network comprising eight nodes v1, . . . , v8 connected to each other with links E1 a, E8 a, E1 b, E8 b. In general, networks are modelled as a graph g={ν, ϵ}, where ν is a set of nodes e.g., v1, . . . , v8, and E is a set of directed links e.g., E1 a, . . , E8 a, E1 b, E8 b, connecting nodes to each other. If there exists a physical connection between two nodes v_(i) and v_(j) then this physical connection provides two links one link per communication direction, i.e., communication is possible in both direction between two nodes. Formally, if nodes v_(i) and v_(j) are connected to each other, then two directed links e_(i,j), e_(j,i) ∈ ϵ are defined. Nodes may be the source or destination of frames or may forward frames to other nodes. In one realization, the links may be Ethernet links and each node of the real-time network is one selected from a group consisting of an Ethernet switch, a router and an end station.

Nodes communicate with each other by the concepts of streams and frames. A stream (or flow) is a periodic multicast data transmission from one talker (the sender) to one or multiple listeners (the receivers). We denote the set of streams in the network with

. We denote the route of a stream s_(i) E

from talker ν₁ to listener ν_(n) routed through the intermediary nodes (i.e. switches) ν₂, ν₃, . . . , v_(n−1) as

_(i)=[e₁, . . . , e_(n−1)].

We assume that for each stream the sender and receiver nodes ν₁, ν_(n), as well as the routed communication path connecting them are known.

A stream s_(i) ∈

is defined by the tuple

C_(i), T_(i), L_(i), J_(i)

, denoting the frame size in bytes, the period, the maximum allowed end-to-end latency, and the maximum allowed jitter of the stream, respectively.

The instance of a stream s_(i) ∈

routed through link e ∈ ϵ is defined by a set of frames f_(i,j) ^(e)∈

_(i) ^(e), where

_(i) ^(e) ⊂

^(e) is the set of all frames of stream s_(i) that are to be scheduled on link e. We denote the set of all frames routed through link e with

^(e). Since streams may have different periods resulting in an overall schedule cycle (also called hyperperiod) larger than any individual stream period, when constructing the GCL we must consider all instances of a specific stream repeating until the schedule cycle. Hence, a set

_(i) ^(e) will have T_(s)/T_(i) frames, where T_(s) is the schedule cycle of all scheduled streams in the network, calculated as the least common multiple of the periods of all streams s_(i) ∈

. Additionally, each such periodic frame on link e ∈ ϵ is characterized by a frame transmission duration l_(i) ^(e) calculated based on the data size C_(i) of the stream s_(i) and the speed of the egress port associated to the physical link e. For example, a minimum- and a maximum-sized Ethernet frame of 84 and 1542 bytes (including the IEEE 802.1Q tag) have a duration of 0.672 μsec and 12.336 μsec on a 1 Gbit/sec link, respectively.

FIG. 2 depicts an example stream and examples of frames in the example real-time network depicted in FIG. 1. In this example a stream S1 is shown in which node v1 is the sender and v7 and v8 are the receiver nodes. Communication along the stream is executed in form of frames, which are depicted as F1, F2, F3, and F4. In one realization the frames communicated may be Ethernet frames.

FIG. 3 depicts an example of a possible realization of an inner structure of a node. This example may be a realization of node v4 from the example network presented in FIG. 1. The node receives frames in its incoming links E1 a, E2 a, E3 a. A switching logic SW1 decides to which outgoing link E5 a the frames must be relayed and to which queue from a set of queues Q1, Q2, Q3, associated with the respective outgoing link E5 a, the frames need to be placed. Furthermore, the figure depicts gates G1, G2, G3 associated with queues Q1, Q2, Q3. These gates are either in an open or in a closed state as indicated by configuration data GCL and the progress in time as indicated by a local clock C1. The node also maintains a transmission selection block TS that selects the next frame from the queues Q1, Q2, Q3 for transmission. The transmission selection TS will only select frames from a given queue Q1, Q2, Q3, if the associated gate G1, G2, G3 is in the open state.

FIG. 4 depicts an example on how the frames F1-F4 of the example stream S1 from FIG. 2 are scheduled and communicated in the example network of FIG. 1. The succeeding events of changing the state of a gate from closed to open and from open to closed define a window W1-W4. An array κ_(i,j) ^(e) denotes the assigned queue for each window on link e ∈ ϵ. We denote the maximum number of windows per link e ∈ ϵ derived with

^(e).

In order to encode the scheduling problem in

, we define for each link e two arrays, φ^(e) and τ^(e) over a sort array, containing the integer variables for, respectively, the open O1-O4 and close time instants C1-C4 of the windows indexed by the position in both arrays for the egress port associated to link e. Furthermore, we define for each frame instance f_(i,j) ^(e)∈

_(i) ^(e)a window index ω_(i,j) ^(e) over the sort index representing the frame-to-window assignment index in both aforementioned arrays. Open O1-O4 and close C1-C4 time instants are measured with respect to a synchronized time in the network. The synchronized time can be established in the nodes, for example, by means of the IEEE 1588 standards and/or the IEEE 802.1AS standards and/or the SAE AS6802 standard or any revision of said standards.

FIG. 5 depicts a flowchart of a configuration method according to the invention. The flowchart consists of a first step REQ in which the communication requirements are collected. This can be done for example by means of a human user input or by autonomous requests from elements within the network. In one realization OPC Unified Architecture OPC/UA [3] is used for formulating these requests. In another realization Network Configuration Protocol (NETCONF) [4] and YANG [5] are used for formulating these requests. In another realization Data Distribution Service (DDS) [6] is used for formulating these requests. In another realization Simple Network Management Protocol (SNMP) [7] is used for formulating these requests. Once the communication requests are collected they are formulated as constraints in array theory in the second step CON. In the third step TOOL the constraints in array theory are provided to a tool that is capable of finding solutions to constraints formulated in array theory. In a fourth step CONF the tool returns configuration data that satisfy the constraints in array theory from step two CON. In a fifth step DIST at least some of the configuration data is distributed in the network and at least some of the node in the network will adapt at least some of the configuration data as their local configuration. This distribution may be executed by protocols, like OPC/UA, DDS, NETCONF/YANG, SNMP, etc.

FIG. 6 depicts constraints in array theory. Usually, all of the constraints presented in the following are necessary, however, in certain applications only one or some of the constraints formulated below are provided.

-   -   Well-formed Windows Constraints:     -   We first formalize logical constraints for all windows of an         egress port. Since each physical link connects one egress port         to one ingress port, we assume an equivalence in the formalism         between an egress port and the connected directed edge (physical         link). We constraint the open and close events of each window         defined on that link to be greater than or equal to 0 and less         than or equal to the schedule cycle of all streams in the         network. Hence, we have the constraint CON-WELLFORMED:

∀e ∈ ϵ:∀k ∈ {1, . . . , W ^(e)}:

(φ^(e) [k]≥0)∧(τ^(e) [k]<T _(s)).

-   -   where, as defined above, T_(s) is the schedule cycle         (hyperperiod) of all communication streams in the network.     -   Queue Assignment Constraints     -   Each window is assigned to an egress queue scheduled in the         range [0.. MAX], therefore we add the bounds for the queue         assignment array CON-QUEUEASS:

∀e ∈ ϵ:∀k ∈ {1, . . . , W ^(e)}.

0≤κ^(e) [k]<MAX

-   -   Stream Instance Constraints     -   As discussed above, communication in network deployments rarely         appear with a normalized period. Instead, streams are sourced at         multiple rates which result in a hyperperiod defining the length         of the schedule tables to be at least the least common multiple         of all periods involved. The assignment of frames, and, as a         consequence, the length of each window, is a result of the         scheduler. Streams routed through the same link having different         periods will contribute a number of frame instances, each to be         scheduled within each period instance occurring until the         hyperperiod. As a result, the open and close bounds for each         window is further constraint to set the window.     -   For each stream s_(i) routed through e we construct the         following constraint CON-STREAMINST:

$\forall{s_{i} \in {\text{:}\mspace{14mu} {\forall{e \in {\mathcal{E}\text{:}\mspace{14mu} {\forall{j \in {\left\lbrack {0,{\frac{T_{s}}{T_{i}} - 1}} \right\rbrack \text{:}}}}}}}}}$ (φ^(e)[ω_(i, j)^(e)] ≥ j × T_(i))⋀(τ^(e)[ω_(i, j)^(e)] < (j + 1) × T_(i)).

-   -   Ordered Windows Constraints     -   An essential constraint for determinism is that no two frames         transmitted on the same egress link are scheduled to overlap in         the time domain. Moreover, we explicitly forbid multiple windows         to remain open at the same to avoid the non-determinism         introduced by contention.     -   Conceptually, the formulation of this constraint does not allow         any two windows on the same link to overlap, which we define as         CON-ORDWIND1:

∀e ∈ ϵ:∀i,j ∈ {1, . . . , W ^(e) }, i≠j:

(τ^(e) [i]≤φ ^(e) [j])∨(τ^(e) [j]≤φ ^(e) [i])

-   -   Note that this formulation results in a large number of         assertions with a disjunction operator, which has proved to be         computationally intensive. However, since the assignment of         frames to windows is not restricted beforehand and any frame may         be assigned to any window, we can simplify this constraint if         the order of windows on each link is predefined offline, hence         fixing their respective open and close events to be sequential.         Therefore, the following alternative formulation may be used         CON-ORDWIND2:

∀e ∈ ϵ:∀i ∈ {1, . . . , W ^(e)−1},

τ^(e) [i]≤φ ^(e) [i+1]

-   -   Frame-to-window Assignment Constraints     -   The frame-to-window assignment variable defines the index in the         three arrays (open, close, and queue assignment) of the         respective egress port. Thus, we restrict the variables to be no         larger than the configurable maximum number of windows per port         CON-FRTOWIND:

∀e ∈ ϵ:∀f _(i,j) ^(e) ∈

^(e):

(ω_(i,j) ^(e)≥1)∨(ω_(i,j) ^(e) ≤W ^(e))

-   -   Window Size Constraints     -   Since frames are assigned to windows by a scheduler, i.e., they         are not known a-priori, the size of a window results from the         accrued sum of the duration of all frames assigned to it. Hence,         we must ensure that the close event of each window allows         sufficient time to transmit the set of assigned frames. We note         that this constraint is the first and only one in our formalism         requiring the store operation of array theory.     -   We start by storing the uninterpreted term for each open         variable in the respective position of the close array         CON-WINDSIZE1:

∀e ∈ ϵ:∀k ∈ {1, . . . , W ^(e)}:

τ^(e)

k←φ ^(e) [k]

-   -   This is equivalent to set all close events equal to the open         event at the same index, therefore initializing the length the         window to 0. Note that this way, the close event of all windows         without any frame assigned will remain equal to the respective         open event.     -   We now construct at each position in the close array the sum         over the duration of all frames assigned to that window, using         the frame-to-window assignment index CON-WINDSIZE2:

∀e ∈ ϵ:∀f _(i,j) ^(e) ∈

^(e):

τ^(e)

ω_(i,j) ^(e)←τ^(e)[ω_(i,j) ^(e) ]+l _(i) ^(e)

-   -   The construct iterates for all frames, adding the frame duration         to the previous uninterpreted value for the close event of the         window to which the frame is assigned and storing the result at         the same index as a new uninterpreted expression.     -   Stream Constraints     -   The stream constraints describe the sequential nature of         communication from talkers to listeners. The generic condition         is that frames belonging to the same stream must be scheduled         sequentially with respect to time along the routed communication         path. Hence, we have CON-STREAM:

∀s_(i) ∈ :  ∀e_(k) ∈ _(i), k ∈ {1, … , n − 1}: $\forall{j \in {\left\{ {0,\ldots \;,{\frac{T_{s}}{T_{i}} - 1}} \right\} \text{:}}}$ ∀f_(i, j)^(e_(k)) ∈ ℱ_(i)^(e_(k)): ∀f_(i, j)^(e_(k + 1)) ∈ ℱ_(i)^(e_(k + 1)): τ^(e_(k))[ω_(i, j)^(e_(k))] + δ ≤ φ^(e_(k + 1))[ω_(i, j)^(e_(k + 1))],

-   -   where δ is the constant value representing the network         precision.     -   In other words, the propagation of frames of a stream follow the         sequential order along the path. Therefore, the window open         event of each frame has to be larger or equal than the close         event of the window assigned to the predecessor frame, plus the         network precision constant to compensate for clock differences         between the two hops.     -   Stream Isolation Constraints     -   It is plausible that at runtime, a network may experience frame         losses or streams showing differences in their periodic payload         size. Therefore, to ensure that the execution of the schedule         during runtime conforms to the offline planning we need to         compute a schedule providing guarantees on the deterministic         state of each queue at any given instant of time.     -   Consider the case in which two streams s_(i) and s_(j) are         received from different links, e_(x) and e_(y), respectively, on         device a and both forwarded to the same egress port on link         e_(a). If their frames are put in the same queue, the order of         frames in that queue may differ during runtime depending on         minimal variations on the exact order of arrival, or the         processing mechanism for ingress ports in the switch fabric.         Moreover, frame losses in one or the other stream may equally         introduce differences in the queue state at each period         instance. Hence, the offline scheduled opening and closing of         the egress queue may effectively cause a different behavior at         runtime induced by the non-deterministic state of the queue.     -   Guaranteeing determinism implies that all frames respect their         computed window assignment throughout the operation of the         network. For that, we need to either assign the respective         frames of the two streams in the example above to the same         window or else isolate them in the time domain, restricting that         the frame of the second stream is not received until the frame         of the other stream has already been scheduled for egress.         Alternatively, if multiple queues are available for scheduled         traffic we can isolate the two frames in windows of different         queues, in which case they may as well be received within         overlapping intervals without altering the run-time behavior.     -   Hence, we formulate the stream isolation condition for streams         s_(i) and s_(j) sent on link e_(a,b) as CON-STREAMISOL:

$\forall{k \in {\left\lbrack {0,{\frac{T_{s}}{T_{i}} - 1}} \right\rbrack \text{:}\mspace{14mu} {\forall{l \in {\left\lbrack {0,{\frac{T_{s}}{T_{j}} - 1}} \right\rbrack \text{:}}}}}}$ ((τ^(e_(a))[ω_(i, k)^(e_(a))] + δ ≤ φ^(e_(y))[ω_(j, l)^(e_(y))])⋁(τ^(e_(a))[ω_(j, l)^(e_(a))] + δ ≤ φ^(e_(x))[ω_(i, k)^(e_(x))]))⋁(κ^(e_(a))[ω_(i, k)^(e_(a))] ≠ κ^(e_(a))[ω_(j, l)^(e_(a))])⋁(ω_(i, k)^(e_(a)) = ω_(j, l)^(e_(a))),

-   -   where the three disjunctive conditions guarantee that either one         of the two frames is received when the other one has already         been forwarded (by comparing the sequence of the respective open         and close events of the windows assigned to each frame), or each         is assigned to a different queue (and hence to a different         window), or both frames are assigned to the same window (and         hence to the same queue).

FIG. 7 depicts a real-time network similar to the network in FIG. 1, however in this example of a network according to the invention an additional node v9 is used. This node v9 implements a device CNC where said tool is capable of solving constraints in array theory. Communication requirements can for example be communicated by a human user to the device CNC by a user interface. In another realization communication requirements can be autonomously provided by some of the nodes v1-v8 in network for example by means of standard network protocols and data models such as OPC/UA, DDS, NETCONF/YANG, SNMP, etc. In another realization node v9 may reside in a cloud-like infrastructure and the links E9 a and E9 b may be Internet connections (involving potentially many Ethernet links, switches, and routers).

REFERENCES

[1] Institute of Electrical and Electronics Engineers, “802.1Qbv—Enhancements for Scheduled Traffic,” 2017. available from http://www.ieee802.org/1/pages/802.1bv.html.

[2] A. R. Bradley, Z. Manna and H. B. Sipma, “What's Decidable About Arrays?,” in VMCAI, 2006.

[3] OPC Unified Architecture, available from https://opcfoundation.org/about/opc-technologies/opc-ua/

[4] Network Configuration Protocol (NETCONF) IETF RFC 6241, available from https://tools.ietf.org/html/rfc6241

[5] YANG—A Data Modeling Language for the Network Configuration Protocol (NETCONF) IETF RFC 6020, available from https://tools.ietf.org/html/rfc6020

[6] Data Distribution Service (DDS) available from http://www.omg.org/spec/DDS/1.4

[7] Simple Network Management Protocol (SNMP) e.g., version 3 IETF RFC 3411-3418, available from https://www.ietf.org/rfc.html 

1. A method to configure nodes (v1, . . . , v8) in a real-time network, which nodes (v1, . . . , v8) of the real-time network are connected with links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) to each other directly or indirectly via other nodes (v1, . . . , v8) and communicate with each other using said links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) by exchanging frames (F1, . . . , F4), wherein at least one node (v1, . . . , v8) associates at least one queue (Q1, . . . , Q3) with at least one link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), wherein said at least one node (v1, . . . , v8) is connected to said at least one queue (Q1, . . . , Q3), and wherein said at least one node (v1, . . . , v8) places frames (F1, . . . , F4) in said at least one queue (Q1, . . . , Q3) for transmission on the associated link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), and wherein said at least one queue is associated with a gate (G1, . . . , G3) which can be in an open state or in a closed state, and wherein said at least one node selects (TS) frames that are placed in said at least one queue on the at least one link associated with said queue for transmission if the state of the gate associated with said queue is in the open state and does not select frames for transmission from said queue on said link when said gate is in the closed state, and wherein said gate changes the state with the progress of time from open to closed and from closed to open to form windows (W1, . . . , W4) as indicated by configuration data (GCL), wherein: said configuration data (GCL) is produced by a tool, wherein said tool is capable of solving constraints in array theory, and wherein said tool accepts input, which input is formulated as constraints in array theory (CON), and wherein said input is provided to said tool by means of human user input and/or by means of communication requests from one, two, or more nodes in the real-time network, and wherein said configuration data (GCL) is communicated to one, two, or more nodes (v1, . . . , v8) in the real-time network, node or nodes which applies/apply at least parts of said configuration data (GCL) or said configuration data (GCL) as local configuration.
 2. The method according to claim 1, wherein some of the constraints in array theory are well-formed windows constraints (CON-WELLFORMED) and/or queue assignment constraints (CON-QUEUEASS) and/or stream instance constraints (CON-STREAMINST) and/or ordered windows constraints (CON-ORDWIND1, CON-ORDWIND2) and/or frame-to-window assignment constraints (CON-FRTOWIND) and/or window size constraints (CON-WINDSIZE1, CON-WINDSIZE2) and/or stream constraints (CON-STREAM) and/or stream isolation constraints (CON-STREAMISOL).
 3. The method according to claim 1, wherein an SMT-solver is used as said tool that is capable of solving expressions in array theory.
 4. The method according to claim 1, wherein that OPC/UA and/or DDS and/or NETCONF/YANG and/or SNMP and/or FTP is or are used to communicate the communication requirements to said tool and/or to communicate configuration data (GCL) to the nodes (v1, . . . , v8).
 5. The method according to claim 1, wherein each node of the real-time network is one selected from the group consisting of an Ethernet switch, a router, and an end station.
 6. The method according to claim 1, wherein the state change from open to closed and closed to open is executed according the IEEE 802.1Qbv standard.
 7. The method according to claim 1, wherein a synchronized time is established in the nodes, preferably by means of the IEEE 1588 standards and/or the IEEE 802.1AS standards and/or the SAE AS6802 standard or any revision of said standards.
 8. A device (CNC) to configure nodes (v1, . . . , v8) in a real-time network, which nodes (v1, . . . , v8) of the real-time network are connected with links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) to each other directly or indirectly via other nodes (v1, . . . , v8) and communicate with each other using said links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) by exchanging frames (F1, . . . , F4), wherein at least one node (v1, . . . , v8) associates at least one queue (Q1, . . . , Q3) with at least one link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), wherein said at least one node (v1, . . . , v8) is connected to said at least one node (v1, . . . , v8), and wherein the at least one node (v1, . . . , v8) places frames (F1, . . . , F4) in said at least one queue (Q1, . . . , Q3) for transmission on the associated link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), and wherein said at least one queue is associated with a gate (G1, . . . , G3) which can be in an open state or in a closed state and said at least one node only may select (TS) frames that are placed in said at least one queue on the link associated with said queue for transmission if the state of the gate associated with said queue is in the open state, and does not select frames for transmission from said queue on said link when said gate is in the closed state, and wherein said gate changes the state with the progress of time from open to closed and from closed to open to form windows (W1, . . . , W4) as indicated by configuration data (GCL), wherein: the device is capable of producing configuration data (GCL) by executing a tool, where said tool is capable of solving constraints in array theory, and wherein said tool is configured to accept input, which input is formulated as constraints in array theory (CON), wherein said input is provided to said tool by means of human user input and/or by means of communication requests from one, two, or more nodes in the real-time network, and wherein the device is configured to communicate said configuration data (GCL) to the one, two, or more nodes (v1, . . . , v8) in the real-time network, which applies/apply at least parts of said configuration data (GCL) as local configuration.
 9. The device according to claim 8, wherein some of the constraints in array theory are well-formed windows constraints (CON-WELLFORMED) and/or queue assignment constraints (CON-QUEUEASS) and/or stream instance constraints (CON-STREAMINST) and/or ordered windows constraints (CON-ORDWIND1, CON-ORDWIND2) and/or frame-to-window assignment constraints (CON-FRTOWIND) and/or window size constraints (CON-WINDSIZE1, CON-WINDSIZE2) and/or stream constraints (CON-STREAM) and/or stream isolation constraints (CON-STREAMISOL).
 10. The device according to claim 8, wherein an SMT-solver is used as said tool that is capable of solving expressions in array theory.
 11. A real-time network comprising nodes (v1, . . . , v8), which nodes (v1, . . . , v8) of the real-time network are connected with links (E1 a, E8 a, E1 b, E8 b) to each other directly or indirectly via other nodes (v1, . . . , v8) and communicate with each other using said links (E1 a, E8 a, E1 b, E8 b) by exchanging frames (F1, . . . , F4), wherein at least one node (v1, . . . , v8) associates at least one queue (Q1, . . . , Q3) with at least one link (E1 a, E8 a, E1 b, E8 b), wherein said at least one node (v1, . . . , v8) is connected to said at least one queue (Q1, . . . , Q3), and wherein said at least one node (v1, . . . , v8) places frames (F1, . . . , F4) in said at least one queue (Q1, . . . , Q3) for transmission on the associated link (E1 a, E8 a, E1 b, E8 b), and wherein said at least one queue is associated with a gate (G1, . . . , G3) which can be in an open state or in a closed state, and wherein said at least one node selects (TS) frames that are placed in said at least one queue on the at least one link associated with said queue for transmission if the state of the gate associated with said queue is in the open state and does not select frames for transmission from said queue on said link when said gate is in the closed state, and wherein said gate changes the state with the progress of time from open to closed and from closed to open to form windows (W1, . . . , W4) as indicated by configuration data (GCL), wherein: for configuring nodes (v1, . . . , v8) of the real-time network the real-time network comprises at least one device according to claim
 8. 12. The network according to claim 11, wherein OPC/UA and/or DDS and/or NETCONF/YANG and/or SNMP and/or FTP is or are used to communicate the communication requirements to said tool and/or to communicate configuration data (GCL) to the nodes (v1, . . . , v8).
 13. The network according to claim 11, wherein each node of the real-time network is one selected from a group consisting of an Ethernet switch, a router and an end station.
 14. The network according to claim 11, wherein the state change from open to closed and closed to open is executed according the IEEE 802.1Qbv standard.
 15. The network according to claim 11, wherein a synchronized time is established in the nodes, preferably by means of the IEEE 1588 standards and/or the IEEE 802.1AS standards and/or the SAE AS6802 standard or any revision of said standards.
 16. A real-time network comprising nodes (v1, . . . , v8), which nodes (v1, . . . , v8) of the real-time network are connected with links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) to each other directly or indirectly via other nodes (v1, . . . , v8) and communicate with each other using said links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) by exchanging frames (F1, . . . , F4), wherein at least one node (v1, . . . , v8) associates at least one queue (Q1, . . . , Q3) with at least one link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), wherein said at least one node (v1, . . . , v8) is connected to said at least one queue (Q1, . . . , Q3), and wherein said at least one node (v1, . . . , v8) places frames (F1, . . . , F4) in said at least one queue (Q1, . . . , Q3) for transmission on the associated link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), and wherein said at least one queue is associated with a gate (G1, . . . , G3) which can be in an open state or in a closed state, and wherein said at least one node selects (TS) frames that are placed in said at least one queue on the at least one link associated with said queue for transmission if the state of the gate associated with said queue is in the open state and does not select frames for transmission from said queue on said link when said gate is in the closed state, and wherein said gate changes the state with the progress of time from open to closed and from closed to open to form windows (W1, . . . , W4) as indicated by configuration data (GCL), wherein: for configuring nodes (v1, . . . , v8) of the real-time network the real-time network comprises at least one device according to claim
 9. 17. A real-time network comprising nodes (v1, . . . , v8), which nodes (v1, . . . , v8) of the real-time network are connected with links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) to each other directly or indirectly via other nodes (v1, . . . , v8) and communicate with each other using said links (E1 a, . . . , E8 a, E1 b, . . . , E8 b) by exchanging frames (F1, . . . , F4), wherein at least one node (v1, . . . , v8) associates at least one queue (Q1, . . . , Q3) with at least one link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), wherein said at least one node (v1, . . . , v8) is connected to said at least one queue (Q1, . . . , Q3), and wherein said at least one node (v1, . . . , v8) places frames (F1, . . . , F4) in said at least one queue (Q1, . . . , Q3) for transmission on the associated link (E1 a, . . . , E8 a, E1 b, . . . , E8 b), and wherein said at least one queue is associated with a gate (G1, . . . , G3) which can be in an open state or in a closed state, and wherein said at least one node selects (TS) frames that are placed in said at least one queue on the at least one link associated with said queue for transmission if the state of the gate associated with said queue is in the open state and does not select frames for transmission from said queue on said link when said gate is in the closed state, and wherein said gate changes the state with the progress of time from open to closed and from closed to open to form windows (W1, . . . , W4) as indicated by configuration data (GCL), wherein: for configuring nodes (v1, . . . , v8) of the real-time network the real-time network comprises at least one device according to claim
 10. 